1. Field of the Invention
The present invention relates generally to accessing network server resources and, more particularly, to a system and method for providing interpreter applications access to server resources in a distributed network.
2. Related Art
Internetworking is the process of establishing and maintaining communications and transferring data among multiple nodes in a distributed network system. The nodes are connected by a common communication medium such as copper or fiber optic cabling and may have a series of intermediate active nodes, such as routers or bridges. The nodes communicate with each other using a common information exchange protocol, such as IPX or TCP/IP.
The purpose of an internetwork is to provide end-to-end service between a client node and a server node to share resources such as information stored in files, databases, etc.; print, facsimile, CD-ROM and other services; and other resources located locally and remotely relative to the server. The client and server nodes are generally computers such as workstations and PCs.
The client node typically includes application programs that request access to resources located on the server node. The server node, which may be, for example, a NetWare(copyright) server available from Novell, Incorporated or a Windows NT(copyright) server available from Microsoft Corporation, is typically a computer dedicated to providing access to the above resources in response to requests generated by the client nodes. (NetWare is a registered trademark of Novell, Inc., and Windows NT is a registered trademark of Microsoft Corp.)
When the client application makes a request, the request is intercepted by a redirector in the client node and passed either to the local operating system or to network client libraries and a network client process for transmission to the server node. The network client libraries translate the request parameters from the library environment to a format appropriate for the network client process. The network client process places the request parameters into a network packet and invokes a network driver on the client node. The network driver packages the request and forwards it onto the network using an appropriate packet format and media-access method. The request is received by a corresponding network driver on the server node that provides the request to a request handler in the server. The request handler, which is typically part of the server operating system, performs the necessary operations to process the request. The resulting reply is returned to the client node in a similar manner.
It is well known that different versions of an application program are generally required to enable it to operate with different types of operating systems. For example, WordPerfect(copyright) for Windows 95(trademark) will not function on the Windows(trademark) 3.1 operating system. (WordPerfect is a registered trademark of Corel, Inc., Windows 95 is a trademark and Windows is a registered trademark of Microsoft Corp.) To enable a single version of an application to execute on different types of operating systems, programs providing a standard application program interface (API) have been recently developed. These programs, referred to as interpreter programs or simply interpreters, operate at a functional level above the client or server operating system. The interpreter program, referred to hereinafter as an interpreter system, executes application programs written in the language of the interpreter system. These applications are referred to hereinafter as interpreter applications. The interpreter system isolates the interpreter applications from the particular requirements of each type of operating system.
An interpreter system generally includes an interpreter engine and interpreter libraries. The interpreter engine translates interpreter applications to system-level instructions appropriate for the host (client or server) operating system. Unlike a compiler which converts programs written in a higher level language (source code) to system-level instructions (object code) for subsequent execution by the processor, the interpreter engine executes source code by translating interpreter commands directly into processor instructions and executing these instructions on the processor. The interpreter libraries define the API that performs functions such as input/output, networking and utility functions utilized by the interpreter applications to access client and server resources. Examples of interpreter systems include the Java Virtual Machine(trademark) (Java(trademark)) and the associated Java Development Kit (JDK) available from Sun Microsystems, ActiveX(trademark) available from Microsoft Corporation, and the widely available Smalitalk interpreter, which executes instructions written in the Smalltalk programming language. (Java Virtual Machine and Java are trademarks of Sun Microsystems, Inc. and ActiveX is a trademark of Microsoft Corp.)
Generally, the interpreter libraries are implemented in an object-oriented programming language and are generally referred to as object or class libraries. The interpreter libraries include a number of service libraries. Two of these service libraries which are of particular importance to the present invention are the commonly known network service libraries and the input/output (I/O) service libraries. The I/O service libraries provide the interpreter application with the ability to access local resources on the client node. For example, the I/O service libraries include objects for reading and writing to a file. The technique which is used by these objects is based upon the concept of a stream. A stream is a sequence of data, such as strings or arrays of bytes or other objects, transferred over a period of time from/to a desired resource. In particular, these I/O libraries include a generic xe2x80x9cstreamxe2x80x9d object class whose methods could be extended to operate on a structure such as a file. For example, when an interpreter application accesses a local file on a client node, stream objects enable the interpreter application to perform file operations such as reading and writing a stream of data to/from the local file. In Java, generic stream objects are extended by file stream objects which use the same programming interface. Other stream objects are used by an interpreter application to operate on a local file.
Network service libraries provide the interpreter application with the ability to access server resources using an application-level communications protocol. Also, interpreters such as Java often include what is commonly referred to as distributed objects, which allow an interpreter system of a first node to transfer a request directly to an interpreter system on a second node for processing. When implementing distributed objects, the interpreter system transfers a request from the interpreter application to distributed objects on the first node which then transfers the request to distributed objects on the second node. The distributed objects on the server node execute the request as if the request was generated locally and returns a reply to the requesting distributed objects on the client node. The requesting distributed objects provide the interpreter application with the reply as if it was generated locally. Different types of distributed object systems exist, such as CORBA, RMI, and DCOM.
Although interpreter systems provide a standardized API, the I/O service libraries do not include objects that support the file access methods necessary to access a particular class of server nodes that require access to occur through an installable file system (IFS). As is well known, an installable file system is an interface found on client operating systems which allows network vendors to provide access to file systems which would normally be foreign to the client operating system. Servers that support communication with an IFS on a client node include, for example, NetWare, Windows NT and Network File System (NFS) servers.
A conventional approach for providing interpreter applications access to resources on servers is to include a software device referred to as a redirector. As noted, a redirector on the client node receives I/O requests from the interpreter and directs the requests either to the local operating system or to the server node. However, for the redirector to direct the resource requests to the client operating system, it must use the programming interface associated with the client operating system. As a result, a different type of redirector is required to support each type of client operating system. For example, commonly available redirectors include Client-32 available from Novell, Inc. for the Windows 95 operating system, NetWare Requester(trademark), also available from Novell, Inc., for the Windows NT operating system, and the Network File System created by Sun Microsystems for the Unix(copyright) operating system. (NetWare Requester is a trademark of Novell, Inc. Unix is a registered trademark, licensed exclusively through X/Open Company, Ltd.) To include a redirector in each client node requires the system developer to incur significant costs associated with the development and maintenance of the different types of redirectors on the numerous, currently existing client operating systems.
Another approach has been to include the functionality that enables the interpreter applications to communicate with the servers within the interpreter object libraries. However, interpreters currently provide limited network service libraries, thereby limiting the type of servers and features that the interpreter applications can use. For example, the network service libraries generally included in Java interpreters only provide the objects necessary to communicate using a network-level protocol such as the TCP/IP information exchange protocol. Java network service libraries do not provide, for example, the objects necessary to use application level protocols with servers such as NetWare, NT, etc. These application level services are generally assumed to be provided by a client redirector. Thus, on clients without redirectors, access to such services is not possible.
What is needed, therefore, is a means for providing interpreter applications with the ability to access a broad range of server resources, regardless of the type of server, without incurring the expense of developing and installing a redirector on existing client nodes. It is also desirable to implement such functionality with minimal modifications to the client and server nodes so that such resource access may be achieved in an efficient and cost effective manner. In addition, it is desirable to provide such functionality without having to use a foreign application programming interface.
The present invention relates to a resource access system and method for providing interpreter applications access to any desired server resource regardless of type of server and current capability of the client node to access such server resources. The invention is an application-level extension of the interpreter system, that locates and accesses a server resource using existing server methods to provide the interpreter application access to a server resource. Also, the invention provides access independent of the type of operating system implemented in the client node by providing access to the server resource at a functional level above the operating system. In addition, the invention utilizes existing techniques, such as distributed objects or an existing client redirector, to communicate with the server. Thus, the invention provides such access to resources on the server node with minimal modifications to either the client or server nodes.
One embodiment of the present invention is implemented when the client node does not include the proper functionality, such as a redirector, to access server resources. Such a redirector would use existing server resource location and access methods defined on the server node to access a server resource. In this embodiment, commonly available distributed object systems are available on both the client and server node. In addition, a stub and a proxy of the resource access system is installed on the client and server node, respectively. The resource access system on each node is associated with an interpreter system on that node. Resource access requests generated by the interpreter application on the client node are received by the resource access system stub on the client node and directly forwarded to the resource access system proxy on the server node using distributed objects. The resource access request is received by a distributed object on the server and forwarded to the server resource access system proxy which then forwards the request to a request handler in the server""s operating system for processing. A reply is generated, and is transferred by a distributed object on the server to a distributed object on the client. The resource access request is processed by the distributed objects on the client and server nodes as if the request was processed on the client node. For example, the invention may be implemented with a Java Virtual Machine (xe2x80x9cJavaxe2x80x9d) interpreter on both the client and server nodes to enable Java applications located on the client node to access resources on a Novell NetWare(trademark) server node. Also, the invention may be implemented with distributed object systems such as Common Object Request Broker Architecture (CORBA), Java Remote Method Invocation (RMI), or Distributed Common Object Model (DCOM).
Advantageously, this arrangement provides server resource access to client interpreter applications without having to install a redirector in the client node. This eliminates the costs associated with creating and maintaining a client redirector for each of the various client operating systems. Importantly, therefore, the client node does not need to be modified in any way other than to install the present invention on the client node for use with the client interpreter.
Another embodiment of the present invention is implemented when the client node includes the proper functionality, such as a redirector, for accessing resources on the server node. In this embodiment, the resource access system is installed only on the client node. Resource access requests from the interpreter application are received by the resource access system and translated into requests for the client redirector. The redirector transfers the request to network client libraries on the client node which then forwards the request to the server. The server node then processes the request in a normal manner. For example, the present invention may be implemented with a Java interpreter on a NetWare client node to enable Java interpreter applications on that node to access NetWare server resources. Advantageously, in this arrangement where the client node includes a redirector, the server node does not have to be modified in any way to enable the interpreter applications to have access to server resources.
Specifically, the resource access system includes a resource locator that obtains location information necessary to access the desired server resource using existing server resource location methods. In response to an interpreter application""s resource request, a resource accessor of the invention accesses the desired server resource as necessary to satisfy the request based on the information provided by the resource locator using existing server resource access methods.
The interpreter system generally includes object libraries to provide a standard application program interface (API) with the interpreter applications. The resource access system is implemented as object-oriented libraries which can be substituted for existing object-oriented libraries. The resource locator includes locator objects which obtain location information for the resource using existing server resource location methods. The resource accessor is comprised of streaming objects that access the server resource using the location information provided by resource locator objects using existing server resource access methods. Preferably, the resource access system objects inherit from the existing interpreter libraries.
Significantly, the resource access system extends the functionality of the existing interpreter libraries, supplementing the standard application programming interface (API) provided by the interpreter. By inheriting from the existing objects, the resource access system objects can be substituted for existing objects for the purpose of accessing server resources. As noted, these server resources may be, for example, a file system or print queue located on the server node.
Significantly, the resource access system provides the interpreter system with the enhanced capability to provide interpreter applications access to server resources. Advantageously, the resource access system enables interpreter applications to use server resources that were not originally designed to access such resources (such as Java applications using NetWare server resources) without custom programming, thereby greatly reducing the cost and effort required to support such applications.
Further features and advantages of the present invention as well as the structure and operation of various embodiments of the present invention are described in detail below with reference to the accompanying drawings. In the drawings, like reference numerals indicate like or functionally similar elements. Additionally, the left-most one or two digits of a reference numeral identifies the drawing in which the reference numeral s first appears.